Quality of Service (QoS) is an important factor for a network to provide a good user experience, especially when all network devices of a wireless network share channel(s). For example, the infrastructure mode based IEEE 802.11g wireless network that is widely used at present has a bandwidth of 54 Mbps.
As shown in FIG. 1, a media server 102 is connected to a TV 103 via a wireless router 101. Since packets sent from the media server 102 need to be sent to the wireless router 101 through the uplink channel 11, and then sent to the TV 103 through the downlink channel 12, and since the uplink and downlink channel are time-division multiplexed, a video stream from the media server 102 to the TV 103 has a maximum bandwidth of 27 Mbps, and the actually available bandwidth for a video stream is smaller due to the obstruction and attenuation of the signals caused by the network environment.
In addition, experiments show that an H.264 compressed, typical high-definition video stream of 1080p needs a bandwidth of 20 Mbps for transmission, as a result, a 802.11g wireless network can accommodate only one high-definition video stream. If other applications requiring large bandwidth also use the network for transmission at the same time and the network does not provide any QoS, it is sure that the play of the video stream will be affected.
Many QoS techniques have been proposed to solve the problem of the allocation of limited resources in a network. Currently prevailing QoS techniques can generally be divided into two types: prioritized QoS and parameterized QoS.
The prioritized QoS marks data packets to be sent according to priorities requested by a user and transmits them in a different priority order, i.e. the data packets marked with higher priority are transmitted in preference to the data packets marked with lower priority. An example of the prioritized QoS is EDCA (Enhanced Distributed Channel Access) in IEEE 802.11e. Although the data packets with high priority are transmitted by preference, data packets having the same priority are still involved in transmission contention.
By contrast, the parameterized QoS reserves some network resources before the transmission starts, HCCA (Hybrid Controlled Channel Access) in IEEE 802.11e being an example of this. Each of the traffic streams needs to provide a TSPEC (Traffic Specification) to send a request to the Hybrid Coordinator in a network before transmission starts. Said Hybrid Coordinator will check to see if the current network status permits said request; if it does, said request by the traffic stream is accepted, and the Hybrid Coordinator allocates to said traffic stream a specific time interval for network transmission, in which period no other stream is allowed to contend with said traffic stream, so it is a contention-free protocol.
The effectiveness of a QoS technique depends on support from lower layer protocol(s) (e.g. physical layer and media access layer in the Open System Interconnect OSI model). However, a lower layer protocol only knows that there are data packets to be transmitted, but it does not know from which application said data packets originate, what kind of priority should be used, or which resources should be reserved. Therefore, the cooperation of upper layer protocol(s), such as providing parameters on the transmission characteristics requirement of the traffic streams and configuring network devices according to these parameters, is necessary to implement the QoS effectively.
The QoS standardization carried out in UPnP (Universal Plug and Play) and IGRS (Intelligent Grouping and Resource Sharing) serve the purpose of defining a set of standard interfaces in an upper layer, so that an upper layer application can invoke the QoS functions provided by a lower layer through said interfaces uniformly. Upper layer herein may refer to network layer, transmission layer, application layer, etc.
The QoS specifications of both UPnP and IGRS are policy-based QoS and define three types of services: QosPolicyHolder service, hereinafter referred to as QPH service, QosManager service, hereinafter referred to as QM service, and QosDevice service, hereinafter referred to as QD service.
QPH service defines a repository of policies of a QoS system; QM service defines management functions of a QoS system; and QD service of a given device defines an interface for setting QoS parameters of the given device.
QM service queries a policy holder with a traffic descriptor, which is provided by a control point when the control point requests to establish a traffic stream, and returns the traffic descriptor allowed by the present system policy holder; the control point executes corresponding QoS actions by invoking the functions of QM; and QM invokes the functions of QD to configure QoS parameters of all devices having implemented the QD service on the transmission path of the traffic stream. Corresponding devices in networks can implement the above-mentioned three types of services to provide corresponding functions. The control point herein may refer to a program or a device defined in UPnP and IGRS specifications which has the function of controlling a device (i.e. invoking the relevant services of the device). For example, a control point may be an audio/video application or a multimedia player installed with the audio/video application.
FIG. 2 depicts the general operation sequence of UPnP and IGRS QoS systems.
A traffic stream may be transmitted directly between the source device and the sink device, and then only two devices are involved in said transmission path.
The traffic stream may also be routed through several network nodes, in which case the transmission path is from the source device to the sink device and through several intermediate devices, which path involves a plurality of devices.
In FIG. 2, a control point CP (which may be an application or a device) initiates a traffic stream transmission from a source device 201 via an intermediate device 202 to a sink device 203.
In an UPnP/IGRS audio/video application, for example, the control point CP may be an audio/video control application; the source device 201 is a media server device, and the sink device 203 is a media renderer/media player Device.
The control point CP provides a Traffic Descriptor (which may include the IP address of the source device 201/sink device 203, the application port, and the average data rate, the peak data rate, the maximum packet length, the maximum allowed time delay of a traffic stream, etc.) in requesting the QM service to establish a transmission.
The QM service uses the traffic descriptor (which may be incomplete) to request the QPH service, the QPH service will check the policy holder and return a matched complete traffic descriptor.
The QD service of a device can provide path information of the traffic stream in which the device is involved according to the link information on network interfaces of the device where it resides. The QM service derives a network topology from the path information provided by the QD service, determines the transmission path of the traffic stream between the source device and the sink device, and configures each of the QD service on the transmission path using the obtained traffic descriptor, i.e. configures the QD service of the device 201, device 202 and device 203.
If the configuration is successful, the QM service will return a status of success to the control point, and then the actual transmission starts.
In a network with QoS, however, some network devices may suddenly fail, such as, disconnected from the network, as a consequence, if the network resources allocated to the failed device cannot be released in time, it will not only lead to a waste of resources, but also cause other devices that require resources to be unable to work properly due to the lack of resources. This problem is particularly notable in parameterized QoS, because the resources are allocated before the actual transmission starts.
Both UPnP QoS and IGRS QoS define a traffic lease time in the QD service specification to ensure that relevant resources can be released in time when a device fails in the network. The traffic lease time defines a time interval in which a traffic stream can use the resources allocated thereto. If the traffic stream needs to continue the use of the allocated resources, the control point has to update the value of the traffic lease time to ensure occupancy of the allocated resources before it expires. If some devices having implemented the QD service fail and the allocated resources cannot be properly released at once, the relevant traffic stream will automatically release the occupied resources when the traffic lease time expires. But if the traffic lease time is set to be too long, and if there are some devices that frequently join and leave the network, it will cause the network resources not to be released in time; whereas if the traffic lease time is set to be too short, too many network resources will be needed to update the traffic lease time, resulting in a heavy load on the network.